N91-21942 


Engineering Software Development with HyperCard 


Robert J. Darko 

Systems Programmer/Analyst 
Hudson Products Corporation 

A case study describing the successful and unsuccessful techniques 
used in the development of software using HyperCard. An 
evaluation of the viability of HyperCard for engineering and a 
discussion of the future use of HyperCard by this particular group of 
developers. 




Engineering Software Development mill — HyperCard 

Abstract: 

A case study describing the successful and unsuccessful techniques 
used in the development of software using HyperCard. An 
evaluation of the viability of HyperCard for engineering and a 
discussion of the future use of HyperCard by this particular group of 
developers. 

Introduction: 

A brief description of Hudson Products Corporation is necessary to 
keep the rest of this paper in perspective. Hudson Products 
Corporation's major products are Air Cooled Heat Exchangers, Steam 
Condensers, and Fans. All of these products are designed in-house. 
Prior to the use of the Macintosh computer two and a half years ago, 
all of these calculations were done using batch software on a mini or 
mainframe computer or were done by hand. The majority of the 
software that existed was written in FORTRAN. 

Much of the software that is used today had their beginnings in the 
60's and 70's, and have gone through many transitions. The ideal 
solution was to rewrite the software and make it easier to maintain, 
but the decision to discontinue the use of the mini and mainframe 
computers as soon as possible was a major factor in some of our 
development decisions. Our first two concerns were the user 
interface and the linking of that interface to a particular software 
package. 

The User Interface: 

HyperCard was chosen as the development environment for the user 
interface. The ease and speed in which a particular interface could 
be created and altered was HyperCard’s strongest point. Having 
chosen HyperCard, we set out on a user interface design. This seemed 
like an easy task, but it was soon discovered to be more difficult than 
had been anticipated. The engineers (as with most users) were set in 
their ways and initially were not open to a great deal of change. 


For example, the three lines of text in figure 1 are a sample of the 
input that the engineers created prior to the use of HyperCard. 
Compare this to the screen depicted in figure 2 that is used today. 
Both figures reflect the same data. 

BOGUS CHEMICAL CO. H92-260-E STEAM CONDENSER SUMMER CASE 1 1 / 1 2 / 90r.nc 

11 900 120 4000 0 5 09 361 1 63600380400 300 0 088100 5 0 

1238 531250 710 3 1 9 9 C 3 1 2 3 3 5 3 0 0 1238 531250 710 3 1 9 90 3123853 OQQOQ 

Figure 1. 


When the development team came up with its initial design they 
assumed that the user would be comfortable with the point and click 
environment that the Macintosh provided. Feedback from the 
existing users showed a great desire to keep hand movement to a 
minimum, but the development team wanted to make the interface 
easy to use for experienced Macintosh users as well. 



The engineers wanted to use the mouse as little as possible, the 
development team wanted to make the data entry as fool-proof as 
possible. Consequently the use of pop-up menus was made when 
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us try a variety of solutions to a given user interface problem, and 
thus pick a solution that fit our needs the best. 
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Figure 3. 



Linking the Interface: 

Getting the user interface linked to the code that does all of the real 
work was another problem. We had a series of programs that 
originally ran in a batch mode that were written in FORTRAN. 
HyperCard had no direct way of communicating with this code. 
Normally an XCMD would be written to handle a series of calculations 
that would be difficult to implement in HyperTalk, but the time 
necessary to rewrite the code in C or Pascal was too involved. 


We decided to use a third party tool that allowed us to convert 
FORTRAN code into an XCMD. This tool involved installing an XCMD 
into every stack that needed to access the FORTRAN code. The stack 
could then invoke this XCMD and pass information indicating which 
FORTRAN routine to run. The XCMD contained a runtime environment 
for the FORTRAN which allowed HyperCard to pass information to the 
FORTRAN code and the FORTRAN code to pass information back. 











This solution worked well at first, but several problems occurred. 
The first problem involved the implementation of the third party 
tool. It was not always consistent in the way that it located the 
FORTRAN subroutine to be run. The initial design required the user 
to have a folder that contained the stack and a subsequent folder 
that contained the FORTRAN code, as shown in figure 4, but due to 
the way that this tool worked the FORTRAN code had to be placed in 
the System folder instead. 
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Figure 4. 


The second problem with this solution was the time and memory 
overhead involved. The FORTRAN runtime package and subroutines 
required that at least 1.5 megabytes be allocated to the HyperCard 
program. This was acceptable, but not always desirable. The time 
overhead involved communication between HyperCard and the 
FORTRAN code. The third party XCMD situated itself between 
HyperCard and the FORTRAN and caused undesirable speed reduction 
in passing parameters back and forth. In fact we discovered that it 
was faster to write the parameters out to an external file and read 
them back in. 

Several tests were conducted to solve each of these individual 
problems. The decision to make each piece of FORTRAN code a stand 
alone program seemed the best solution. This decision allowed us to 
revert to our original design of having the stack and a folder 
containing the FORTRAN programs in a directory of their own as 
shown in figure 4. This made software updates easier to manage 
since the user could copy the contents of one directory to his disk 
and not worry about putting different files in different locations. 

Our communication mechanism was simple. HyperCard would gather 
input from the user, write that data out to a file on disk, and then 




invoke the FORTRAN program. The FORTRAN program would read in 
the data, calculate the results, and write them out to another file, 
which would be read in by HyperCard and then reported to the user. 
All of this worked quickly enough to satisfy our users. 

Other Concerns: 

Another concern after getting the rudimentary portion of our stacks 
to work, was the need to store and fetch data between runs. We 
needed a database management system, but that area was still being 
studied and a complete solution had not been decided on, so a 
temporary solution was devised. 

The easy solution was to save a copy of each stack after the input 
had been made, but there was a lot of overhead in the stacks. In fact 
the stacks themselves had been merged into a single stack which 

totaled more than 250 Kilobytes. Saving this much information was 
going to exhaust our storage rather quickly. The size of the data that 
actually needed to be stored was around 5 Kilobytes. So a scheme 
was devised that allowed us to store and retrieve the data in a text 
file. This technique required that the card design not change 

drastically. The most important restriction was that the deletion of 

fields or buttons was not allowed. We could add some if needed, but 
could not delete them and still be backwards compatible with our 
data format. 

Using the Hierarchical File System of the Macintosh we achieved a 
pseudo-database that allowed our users to fetch related data. This 
worked by putting related files into the same folder, (see figure 5 for 
an example of this hierarchy). This technique lasted for about a 
month before two other problems became apparent. 

The first problem involved the time needed to read and write the 
data files. Several solutions were tried, but the only one that 

achieved any appreciable time reduction was an XCMD. So we coded 
an XCMD to collect the data in memory and then dump it out to the 
disk. The drawback to this was that if we ever added new fields or 
buttons, then we had to recode the XCMD. This was acceptable. 




Figure 5. 


The second problem became two-fold. Users were saving data on 
each of their individual systems. This sometimes led to a duplication 
of information when more than one engineer worked on the same 
problem. The solution here was to modify the stack so that it could 
use a file server instead of the user's hard disk. This was 
accomplished without a significant amount of effort, but within 3 
months we hit another barrier. The number of files created was 
getting rather large. Since this was a temporary solution to begin 
with, we simply added another level of hierarchy to the storage of 
the data. 

Printing was a problem that was handled two ways. The first was 
for simple output, the solution was an XCMD that printed multi-page 
data in a single font. The second was for more complex output. We 
needed to create detailed forms and fill in the form with data from 
the HyperCard stack. For this we turned to a third party product 
called "Reports!". The initial version did the job, but was a bit 
difficult to implement, this product has been revised now and is well 
worth using. 

Future Goals: 

We have already started to implement an SQL database that 
HyperCard will access. This will allow us to link not only our 










engineering data, but our accounting, scheduling, and statistical data 
as well. Other plans include on-line help systems for each of the 
stacks, simple expert systems, and recoding some of our software 
into true XCMDs. 

Evaluation: 

HyperCard has its shortcomings, namely speed and lack of color. The 
speed issue can usually be worked around by use of a compiler or an 
XCMD. Color is a problem that will have to wait until Apple does 
something about it. Fortunately our needs do not necessitate the use 
of color. Card dimensions had caused us some small problems, but 
they too can be worked around. 

HyperCards biggest benefit is its ease of creating a user interface. 
Since it is easy to make modifications to the card design many 
different solutions to a particular problem can be evaluated. We have 
also been able to create a series of tools that all have the same "feel" 
to the user. This has helped keep the need for user training down 
significantly. 

HyperCard has allowed us to accomplish more than we could have 
using conventional development methods. It has proven to be an 
excellent prototyping tool, and a more than adequate environment 
for the implementation of our software. Due to the success with this 
project, new projects are being implemented using HyperCard and 
the techniques described. 
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